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Title : Rekeying in Secure Mobile Multicast Communications 

Description 

Field of the invention 

This invention relates to rekeying in secure mobile multicast communications 
and, more spedfically to inter-area rekeying of encryption ke^. 

Backoround of the invention 

The emergence of new internet applications such as video-conferencing, 
e-leaming and many other applications which are based on group communications 
experience new challenges such as support of user mobility. A new type of 
Internet solution is being specified to allow users to communicate with multiple 
remote hosts while moving in the Internet. In the perspective of deploying 
multiparty-based applications, the Internet Engineering Task Force (IETF) has 
defined the IP multicast model [S. Deering, "Host Extension for IP Multicasting", 
Internet RFC 1112, August 1989]. This model allows any user to send Data Traffic 
in a single copy of its message to a group of hosts knowing only their group 
address, or more exactly their multicast address: members join the group by 
subscription without the sender needing (nor being able) to use the individual 
group members' unicast addresses. The sender's message is then optimally 
duplicated by multicast routers on the path towards the receivers. 

Unfortunately, the IP Multicast model was originally specified without security 
support. This issue remains an obstacle for a broader deployment of IP multicast, 
especially for security-sensitive applications such as Pay-Per-View, private 
conferences and military communications, for example, where data confidentiality 
in a dynamic membership context is necessary. Furthermore, the mobility of users 
complicates the IP multicast security problem. 

While general aspects of the multicast security issues [for example T. 
Hordjono and B. Weis, " The Multicast security (MSEC) Architecture", Internet 
draft, draft-ietf-msec-arch-04.txt. November 2003] and group encryption key 
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management issues [for example Mark Baugher and al., 'The Group Domain of 
Interpretation". Internet RFC 3574, July 2003] have been broadly addressed 
through multiple works and studies, the impact of member's mobility has not been 
widely considered. The expression 'intra-group mobility* is used herein to refer to 
movement of member between administrative areas ('inter-autonomous-system 
mobility'), without leaving or joining a group. The group Is nomnally defined by the 
multicast address to which the member has subscribed. However, In some 
circumstances, it would be desirable for a mobile member to remain part of a 
group defined by the Traffic Encryption Key while changing multicast address. 

Such mobility complicates the IP multicast security problem. In fact, inter- 
autonomous-systemmobility confuses the group membership dynamism since 
mobile members not only wish to join or leave the multicast group, but may also 
wish to move within the group between networks or areas while remaining (from a 
group membership viewpoint) in the secure session. However, member's 
movement between networks or areas may compromise data secrecy. This would 
normally require expensive rekeying (the generation of new keying materials) for 
the existing members in order to ensure data secrecy (Forward and Backward 
Secrecies). Such a constraint is due to the fact that the underiying group key 
management service was only designed for stationary members [M. Baugher, R. 
Canetti, L. Doneti, and F. Lindholm, "Group Key Management Architecture", 
Internet draft, draft-ietf-msec-gkmarch-06.bct, September 2003]. 

The Multicast Security (msec) Working Group of the Internet Engineering 
Task Force (IETF) specifies a common architecture for secure multicast 
communications [T. Hordjono and B. Weis, 'The Multicast security (MSEC) 
Architecture", Intemet draft, draft-ietf-msec-arch-04.bct, November 2003]. This 
architecture defines a security entity used for delivery and management of 
cryptographic keys in secure groups. Such an entity is called the Group Controller 
Key Server (GCKS). The algorithms that manage the distribution, rekeying 
('updating'), and revocation of the group keys are known as group key 
management protocols. The challenge of any key management protocol is to 
generate and distribute new keys such that the data remains secure while the 
overall impact on system performance is minimized. There are two basic designs 
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of group key management model: a centralized design and a distributed design. 

In the centralized design, there Is a single GCKS that manages the keying 
material for all the group members. 

. In a distributed architecture the GCKS entity interacts securely with other 
GCKS entities to provide more scalable group management services, and hence 
to avoid signaling overhead and system bottleneck In the case of a large number 
of group members, which are more likely in the case of a centralized architecture. 
The manager of the entire group — the domain - is called the Domain GCKS. The 
domain is divided into administrative regions called areas. The area may be 
constructed on either a physical or a logical basis. For example, an area may 
represent a Corporate Network, or may contain a set of users that belong to a 
common logical group or coalition. Independently of their physical location. Each 
area Is managed by an area GCKS, a 'local GCKS'. The present invention relates 
to the distributed architecture. 

In order to ensure the confidentiality of multicast application data, the 
Domain GCKS generates and distributes to all group members a common key 
called a Traffic Encryption Key (TEK). This key is used by the multicast source to 
encrypt data traffic, and by receivers to decrypt source's data. In a distributed 
scheme, when the Domain GCKS generates the data key (TEK), It muKicasts it 
securely to each area's local Group Controller Key Server (GCKS). The local 
GCKS Is responsible for distributing the TEK to members within its area in a 
secure fashion using a specific key called: Key Encryption Key (KEK). These keys 
are used by the local GCKS to encrypt the TEK and subsequent KEK versions 
(local rekeying). The means by which the local GCKS distributes keys in a secure 
fashion may include a unicast or multicast secure channel, a logical hierarchy of 
keys or an extension of the server hierarchy. This framework is depicted in Figure 
1 of the accompanying drawings. 

The group is dynamic, so that when a new member joins the group, the TEK 
must be changed to ensure that the newly joining member cannot decrypt 
previous communications; this requirement is called Backward Secrecy. In the 
same way, whenever a member leaves the group session, the TEK must be 
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changed - rekeyed - to ensure that the leaving member cannot decrypt further 
communications using the TEK it held before leaving the session: such a 
requirement Is called FonA/ard Secrecy. In addition, during a secure multicast 
session, keys will have a predetermined lifetinne and will be periodically refreshed 
according to particular intervals. This ensures that no keying material remains 
valid for more than a fixed period of time. 

In more detail, when a new member joins the group through a given area It 
sends the local GCKS a signalling message to request the Group Traffic 
Encryption Key (TEK) as well as the local KEK. The local GCKS then creates and 
multicasts a new KEK to all the existing members of its area encrypted with the 
previous KEK. The new KEK is also unicast to the new member using a secure 
channel established using suitable mechanisnns such as those based on a shared 
key or member's public key. Once the new KEK is distributed in the relevant area, 
the Domain GCKS multicasts the new TEK to all local GCKSs and then each local 
GCKS (GCKSi, GCKSj and so on) fonwards the new TEK to group members In 
their respective areas In one multicast distribution using the respective KEKs 
(KEKi, KEK| and so on). The process of updating the keying material when a new 
member joins the group ensures backward secrecy. As a result, the new member 
cannot have access to an unchanged KEK to decrypt the previous TEK that was 
encrypted with an unchanged KEK, and thus cannot obtain data transmitted prior 
to its arrival. 

When a member leaves the multicast group, all the valid keys It held just 
before leaving the session must be changed by notifying its local GCKS. In this 
case, the member's local GCKS will create and distribute a new KEK to the 
remaining area members. The proposed solutions for Inter-area rekeying we will 
review here suggest using a unicast secure channel to distribute the new KEK to 
each remaining member, instead of multicasting, since for both scalability and 
performance reasons, the GCKS does not have an encryption key shared only 
with all the remaining members (that is to say all except the leaving member), and 
hence the GCKS could not use multicast to send the new KEK only to the 
remaining members. Once the new KEK is distributed, the Domain GCKS 
generates and distributes a new TEK to all the local GCKSs. Each local GCKS 
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then forwards securely the new TEK to all Its area members using the KEK. This 
method ensures forward secrecy. That is, a leaving member cannot decrypt future 
group communications in any area because it does not have the required keying 
materials (i.e. the new TEK and the new KEK). 

In summary, the group key management service is required to ensure the 
following features in respect of all group members, even for group members that 
move intra-group between different areas in the domain - inter-area mobility : 

• Confidentiality: Only group members can read the multicast traffic. 

• Backward secrecy: Every time a new member joins the group, the Traffic 
Encryption Key (TEK) must be changed for all group members to ensure 
that the new member cannot decrypt previously transmitted data traffic. 

• FoHA/ard secrecy: When any group member leaves the multicast group, the 
TEK must be changed for the remaining group members to ensure that the 
leaving member cannot decrypt subsequent data traffic. 

The situation for intra-group inter-area mobility is illustrated in Figure 2, in 
which a current group member MMy initially in the area managed by GCKSi moves 
intra-group to the area managed by GCKSj, a current group member MMji initially 
in the area managed by GCKSj moves intra-group to the area managed by GCKSi, 
and a current group member MMi^ initially in the area managed by GCKSk moves 
intra-group to the area managed by GCKSj. 

It will be appreciated that each area may contain one or more Autonomous 
Systems (ASs) such as Corporate Networks that may represent a distinct 
organization with its own physical network. The ASs may also be limited by 
geographical constraints. Problems have arisen with proposed mechanisms for 
rekeying, due to security policies, key latency and risks of traffic interruptions and 
over-frequent inter-area signalling. 

One known proposal, referred to as a Static Rekey (SR) approach is 
illustrated in Figure 3 [C. Zhang and al., "Comparison of Inter-Area Rekeying 
Algorithms for Secure Wireless Group Communications", IFIP WG 7.3 
Intemational Symposium on Computer Performance Modeling, Measurement and 
Evaluation, September 2000]. In this proposal, the local GCKSi maintains the KEKi 
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unchanged when a mobile member MMg moves intra-group to a new area. That is, 
the mobile member MlVlg will continue receiving the KEKi originating from its 
GCKSi. To achieve this, the GCKSi may use inter-area multicast to distribute 
updates of KEKi for members out of the area. Otherwise, It may use a fonvarding 
node, such as the Home Agent in the case of Mobile IP. 

This approach is straightforward and does not require the mobile member 
MMij to register with the new local GCKSj whenever it moves to a new areaj. In 
addition, movement of the member MMg between the two areas affects neither the 
members of the previous area nor those of the new one. However, the Static 
Relcey approach may not work in case where the mobile member moves to a 
network that belongs to a new administrative area where the security policy 
restricts the traffic and the Interactions with foreign areas. This may be the case 
when the entire network consists of a coalition composed of loosely connected 
ASs (e.g., in cooperative military), for example, or when the keys are multicast to 
the members. Moreover, with the Static Rekey Approach the distribution of keying 
material to members MMg out of their areas may suffer latencies or may even fail. 
Such problems are especially constraining in applications that depend on a rapid 
dissemination of secure infomnation such as military operations, for example. 

In order to reduce both these latencies and inter-AS Signaling, new 
approaches have been defined proposing mapping the logical area structure 
directly onto the physical topology of the network. In addition, these approaches 
propose moving the key changes as close as possible to the members, shifting 
existing trust relationships to the current location of the mobile member to support 
future key exchange and eliminating the member's dependence on a distant 
security server. 

If the inter-area movement of the mobile member MMi] were simply 
considered as a leave from the old area GCKSi followed by a join to the new area 
GCKSj, this case would be assimilated to that of a member joining and/or leaving 
the group altogether. This would introduce an Intenruptlon of data transmission as 
well as additional computations whenever the mobile nnember transfers between 
areas. In addition, new TEKs may be generated twice due to the movement of the 
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member MMq if the Domain GCKS considers that the entering member is both a 
member leaving and a member joining the group. 

Another Icnown proposal, referred to as an Immediate Rekey (IR) approach is 
illustrated in Figure 4 [B. DeCleene, L.Dondeti, S. Griffin, T. Hardjono, D. KIwior, J. 
Kurose, D. Towsley. S. Vasudevan, and C. Zhang, "Secure Group 
Communications for Wireless Networks", Proceedings of Military Communications 
Conference, IEEE MILCOM, Communications for Network-Centric Operations: 
Creating the Information Force. Vienna, October 2001, pp. 113-117]. The 
Immediate Rekey algorithm defines new semantics that address member's 
mobility. In fact, when a group member MMo moves to a new area, it sends a 
signaling message to the previous GCKSi as well as the visited GCKSj. The areas 
GCKSi and GCKSj then update their local KEKs. No TEK rekey is required since 
the member MMy proves its group membership to the new local GCKSj using 
specific information called credentials, for example in the manner described In S. 
Griffin, B. DeCleene, L. Dondetl, R. Flynn, D. KIwior, and A. Olbert," Hierarchical 
Key Management for Mobile Multicast Members. Accordingly, the data 
transmission continues uninterrupted. 

This approach is simple from a key management point of view. In addition, it 
separates the case of intra-group mobile members from that of members entering 
or leaving the group by maintaining the TEK unchanged when a cunrent group 
member moves between areas. However, It implies systematic rekeying of the 
local KEKs KEKi and KEKj for all group members within the areas affected by the 
handover of the mobile member MMj. Thus, the efficiency of this approach is 
seriously affected in the case of group members with a high inter-area mobility. 

Yet another known proposal, referred to as a First Entry Delayed Rekey+ 
Periodic (FEDRP) approach is illustrated in Figure 5 [C. Zhang and al., 
"Comparison of Inter-Area Rekeying Algorithms for Secure Wireless Group 
Communications", IFIP WG 7.3 International Symposium on Computer 
Performance Modeling, Measurement and Evaluation, September 2000]. The 
FEDRP approach is like the IR approach in the use of semantics of transfer 
between areas. It enhances this approach, however, since no local rekeying 



wo 2005/062951 



PCT/US2004/043416 



-8- 

occurs In the previous area. That is, when the member MMo moves intra-group 
from areai to areaj, it sends one signalling message to GCKSi and one signalling 
message to GCKSj. GCKSi then adds the member MMij to a list of members that 
have left the area by Intra-group mobility without leaving the group and still hold a 
valid area key KEKi for a limited period of time. This list is called an Extra Key 
Owner List (EKOL). It is reset when and If a member holding a valid area key 
KEKi. in areai or visiting another area, leaves the group and when the timer of the 
validity period expires. In some cases, the mobile member MMg may accumulate 
multiple KEKs that correspond to different areas it has been in. If the mobile 
member MMg retums to an area it has previously visited, the local GCKS checks if 
this member is on the local EKOL list. If this is the case, it will be removed from 
the list and no rekeying will be needed. In this case, the mobile member MMy 
receives (optionally) the current KEK using a secure channel. However, if the 
member MMij is not present in the list, a new KEKi is generated and sent in one 
multicast distribution to cunrent area members using the previous KEKi, and in a 
u nicest transmission using a secure channel to the mobile member MMij. 

In order to ensure fonward secrecy, when a mobile member MMg visiting 
another area leaves the group session, all the KEKs it holds must be changed for 
all the group members holding those KEKs within the affected areas and, In 
addition, all the EKOL lists holding those KEKs are reset. The KEK that the 
member holds out of areai may also be changed under specific conditions related 
to EKOLi (especially expiration of the key validity period). 

The FEDRP approach improves significantly the inter-area rekeying by 
keeping the KEKi of the previous area GCKSi unchanged. However, the FEDRP 
approach suffers from systematic rekeying when the mobile member enters a new 
area GCKSj for the first time. That is. when the member MMij moves to the new 
area GCKSj, its mobility is supported In the previous area GCKSi, but not in the 
visited area GCKSj. In addition, during the session duration, it is more probable 
that a member enters a given area for the first time than for more than one time. 
As a result, when a member moves between areas, it is highly probable that a 
local rekeying occurs in the visited area. 
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It is desirable to provide a lightweight mechanism that optimizes the 
computation for mobile members while reducing the Impact of their movement on 
group rekeying 

Summarv of the Invention 

The present invention provides a method of and apparatus for inter-area 
rekeying of encryption keys in secure mobile multicast communications as 
described in the accompanying claims. 

Brief description of the drawings 

is a schematic diagram of the architecture of a distributed group key 
management system, showing Traffic Encryption Key distribution 

is a schematic diagram of the group key management system of , showing 
inter-area movement of group members, 

is a schematic diagram of the group key management system of , showing a 
known rekeying method for inter-area movement of group members, 

is a schematic diagram of the group key management system of , showing 
another known rekeying method for inter-area movement of group members, 

is a schematic diagram of the group key management system of , showing 
yet another known rekeying method for inter-area movement of group members, 

is a schematic diagram of a group key management system of the kind 
shown and for inter-area movement of group members in accordance with one 
embodiment of the present invention, given by way of example, is a flow chart of 
an example of a rekeying process when a member joins an area in the system of , 

is a flow chart of an example of a rekeying process when a member leaves 
an area in the system of , and 

is a flow chart of an example of a traffic key reception process in the system 

of. 
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Detailed description of the preferred embodiments 

Embodiments of the present invention shown in the drawings enable a 
reduction in the computational capabilities needed for both the key server and 
area members to support encryption/decryption operations due to membership 
dynamism (group join/leave) and member's frequent mobility, by separating 
member's mobility treatment from group membership dynamism, and by 
amortizing the movement impact over the TEK validity period. In addition 
embodiments of the present Invention provide the following features. 

• Reduced impact of member's mobility on group rekeying: the key 
management system, by separating member's mobility treatment from 
group membership dynamism (group join/leave), facilitates movement of 
mobile members between administrative areas while remaining (from a 
group membership viewpoint) in the group. In addition, when the mobile 
member leaves the group, the rekeying process reacts with a limited 
additional impact on the remaining group members. This residual impact is 
typically due to the accumulated Information that the leaving mobile 
member got from the different areas it visited. 

• Reduced computational requirements for mobile members: mobile 
members have generally very limited resources (e.g. memory space, and 
computational power). Hence, it is useful to minimize for mobile members 
both the memory space requirements (e.g. number and size of stored keys) 
and computations (those involving cryptographic algorithms In particular). 

• Trust in Mobile members: the group key management system foresees a 
level of trust to attribute to mobile members because they may move across 
different managed areas, and accumulate information about local security 
services of the different areas they visit. In particular, for some applications, 
such as military communications, the mobile member must be prevented 
from continuing to hold valid keying material that It got from a specific 
security server -when the mobile member is out of the management area of 
that sen/er for more than a given period. 

More particularly, embodiments of the present invention provide the following 
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enhancements: 

• avoiding rel<eying thie members of the visited area each time a mobile 
member enters it; 

• amortizing the impact of member's movement over the TEK lifetime; 

• providing a conditional self-generation of local keys for mobile members to 
reduce signalling between the local GCKS and its members; 

• saving resource consumption using derived key-based rekeying for mobile 
group members. 

This mechanism enables the impact of member's movement on area 
member rekeying and that of the visited area in particular to be reduced 
significantly. It separates the rekeying of mobile members from membership 
dynamism (group join/leave) without affecting the KEK rekeying process. This is 
achieved by introducing a specific key called Visitor Encryption Key (VEK), which 
is provided to mobile members when they move to a new area. 

In more detail, as shown in Ifigure 6, when the mobile member MMy moves 
form areai to areaj, it sends a signalling message to GCKSi of the area it is leaving 
as well as a signalling message to GCKSj of the area in which it is arriving to notify 
them about its mobility. The signalling messages may be implemented as in 
FEDRP and IR, using credentials, for example as described in S. Griffin, B. 
DeCleene, L. Dondeti, R. Flynn, D. Kiwior, and A. Olbert," Hierarchical Key 
Management for Mobile Multicast Members". Once MMy Is In the new areaj, the 
GCKSj sends the Visitor Encryption Key VEKj rather than the KEKj to the mobile 
member using a secure channel. This key VEKj acts similariy to a KEK within this 
areaj but is not used by members MMj already in the areaj and possessing the 
current KEK). 

There are two types of owner lists for the GCKSs: EKOL (for example similar 
to that described in B. DeCleene, L.Dondeti, S. Griffin, T. Hardjono, D. Kiwior, J. 
Kurose, D. Towsley, S. Vasudevan, and C. Zhang. "Secure Group 
Communications for Wireless Networics", Proceeding of Military Communications 
Conference, IEEE MILCOM, Communications for Networic-Centric Operations: 
Creating the Infomnation Force. Vienna, October 2001, pp. 113-117) and in 
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addition a Visitor-Key Owner List 'VKOL' that distinguishes between group 
members MMi situated in the respective group key management areai and group 
members MM^ that were situated in the respective group key management areai 
areai but are visiting another area areaj. In this embodiment of the present 
invention, Visitor-Key Owner Lists (such as VKOLi) contain the list of members still 
holding a valid VEK (such as VEK) but which have subsequently left the key area 
(areai) in which they obtained the VEK. It Is within the scope of the present 
Invention, however, to modify the system to function In other ways, for example so. 
that the Visitor-Key Owner Lists (such as VKOU) contain the list of members still 
holding a valid VEK (such as VEK) and which are still In the key area (areai) in 
which they obtained the VEK. This may assume that GCKSi can distinguish 
between members holding VEKi and are out of areai from those that are in. For 
example, when the VKOU is reset (as described below) only members with VEK 
and that are out of areai will be removed. 

The flow charts shown in Figures 7 to 9 show In more detail examples of the 
processes that the local GCKS performs in the embodiment of Figure 6 when a 
new member enters or leaves the area. The processes shown Include Group join 
and leave, as well as movement of a current group member between two areas. 

In the embodiment of the invention shown in Figure 6, when a mobile 
member MMy moves intra-group from areai to areaj, the following processes will be 
triggered.: 

• if this mobile member MMb holds a VEKi, the GCKSi places the member in 
the VKOLi list. 

• if the mobile member MMy holds a KEKi, the GCKSi places that member in 
the EKOLi list. 

In both cases, the GCKSi triggers a validity period (as in FEDRP) for the local 
key VEKi or KEKi that the mobile member MMy holds. Subsequently, if the mobile 
member returns to areai during the validity period, the GCKSi removes this 
member from the list and no local rekeying occurs (optionally, GCKSi provides the 
entering member with the current TEK). Accordingly, it Is unnecessary to rekey 
area members when a mobile member returns to a previously visited area. 
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However, if the mobile member remains out of the areai and the period expires, 
the local GCKSi resets the owner list EKOU or VKOU and distributes a new local 
key (KEKi or VEKi) to each concerned local member using a secure channel. 

Once the mobile member MMo enters the areaj, we may distinguish two 
cases: 

• If there are no VEKj-members, the GCKSj generates a VEK| key (rather 
than a new KEKj) and sends it (optionally, along with the current TEK) to 
the visiting member MMo in a secure channel, and the KEKj remains 
unchanged. 

• If VEKj-members exist, the GCKSj checks first whether the cunrent VEKj 
was used to encrypt the previous TEK. If It is not the case, the GCKSj will 
provide the entering mobile member MMij the current VEI^. Otherwise, the 
GCKSj will provide the entering mobile mennber MMy a new VEI^ derived 
from the cun-ent value of VEKj (preferably using a one-way hash function, 
for instance: VEKNew=Hash(VEKcurrBnt)). During the validity period of the 
current TEK, the local GCKSj may not derive more than once a new VEI^ 
value whatever the number of new mobile members that enter GCKSj's 
areaj during the TEK validity period, since the visited GCKSj is unaware 
when the visiting mobile member MMy joined the group in a different area. 

Note that in all cases, no local rekeying (KEKj or VEI^) is triggered whenever 
a mobile current group member MMj moves between two areas. Besides, both 
Backward and Forward secrecies are ensured. Hence, this embodiment of the 
present invention separates fully member's intra-group mobility from group 
membership dynamism (group join/ leave). 

When a new member (as opposed to a current group member entering the 
area by intra-group mobility) joins the group via a given areai where there are VEK- 
members. the local GCKSi will distribute a new KEKi to all the area members 
encrypted separately with the current KEKj and the current VEK. As a result, all 
the cun-ent area members will then hold the new KEKi. The KEKi is distributed by 
unicast to the new member as well using a secure channel. Ne)d, the Domain 
GCKS multicasts securely the new TEK to all the area GCKSs. Each area GCKS 
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then multicasts the new TEK to all the group members using the local area keys 
(local KEKs, and local VEKs when and where there are VEK-members). 

When any group member leaves the multicast group (as opposed to a 
current area member leaving the area by intra-group mobility), all the area keys it 
holds are changed within the affected areas. In this way, for a given areai, the 
GCKSi sends either a new KEKi or a new VEKi (depending on which local key the 
leaving member holds) to the concerned members of the areai using a secure 
channel with each member, which may be any secure channel except that based 
on the compromised encryption key (current VEK/KEK), for example a unicast 
channel. Next, the Domain GCKS multicasts securely the new TEK to all the area 
GCKSs. Each area GCKS then multicasts the new TEK to all the group members 
using the local area keys (local KEKs, and local VEKs when and where there are 
VEK-members) In circumstances where it is desired for a mobile member to be 
able to change multicast address while keeping the same Traffic Encryption Key 
TEK, it is unnecessary to send the mobile member a new TEK or to rekey the 
TEK. 

If the rekey is a KEKi rekey, all the local members will be sent the new KEKi 
and the local VKOL list is reset (previous members who visited the areai are 
absent will no longer hold a valid VEKi); in this case, any group members still in 
the areai that hold a VEKi will switch to the new KEKi. Once in place, the local 
GCKSi distributes the new TEK in one multicast transmission using the local keys. 

However there is no need to change the KEKs of the areai if the leaving 
member held only the VEKi. Hence, we save resource consumption since the local 
KEKi remains unchanged. In fact, in prior art approaches, when a member leaves 
the group session, a new local KEK is distributed individually for each remaining 
area member before a new TEK is multicast to these members. For some 
applications, the multicast traffic is interrupted until the new TEK will be 
distributed. This may increase session interruption latency particularly when the 
number of remaining area members is important. With this embodiment of the 
present invention, when the member leaving areai holds a VEKi and not a KEKi, 
the session interruption latency is significantly reduced whether or not the number 
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of KEKi-members in the affected areai is significant. Such a gain of processing 
time is particularly valuable in real-tinne applications. 

For both group join and leave cases, the EKOU as well as the VKOU lists on 
which the leaving member is listed are reset when the new local key is distributed 
to areai members. 

In summary, In this embodiment of the present invention, the VEKi can be 
considered as a temporary key, since the members holding such a key in a given 
area will switch to the new KEKi when a KEKi rekeying occurs (after a group join or 
periodic rekeying). Any additional processing that management of the VEK may 
Introduce in the GCKSi is negligible. 

It is within the scope of the present Invention, however, to modify the system 
to function in other ways with respect to VEK management, for example, so that a 
new member receives an updated VEK rather than an updated KEK. Another 
modification would suggest that when a member holding a VEKi leaves the group, 
the GCKSi may distribute a new KEKi (rather than updating VEK as described in 
our basic mechanism) for all the remaining area members using a secure channel 
with each of those members. Similariy, when a member leaves the group via areai 
while holding a KEKi, GCKSi may securely unicast a new KEKi for KEKi-members 
only, and VEKi remains unchanged for VEKt-members. In this case, VKOU list will 
not be reset. In another option, when a member joins the group via areai, GCKSi 
may multicast a new KEKi encrypted with KEKi only, and VEKi remains unchanged 
for VEKi-members. In this case, VKOU list will not be reset. 

Each time the local GCKSi needs to fonward a new TEK (TEK rekey) within 
its areai that includes VEKi-members, it multicasts the new TEK separately 
encrypted with KEKi and VEKi. To achieve this, the local GCKSi checks first if it 
has obtained the current VEKi by derivation from the previous one since the 
previous TEK fonvarding. 

If so, the local GCKSi notifies the VEKi-members (within the TEK distribution 
message) that the new TEK they are receiving is encrypted with a new VEKi 
(derived from the previous one see above). The VEKi-members then decrypt this 
new TEK using the derived VEKi (the members obtain the new VEKi by applying 
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the same function to the previous VEKi as the one that was applied by the GCKSi 
server). 

If no derived VEKi value has been generated since the previous TEK 
fonwarding. It means that the VEKi has not been changed since then. Thus, the 
GCKSi encrypts the TEKi with the current value of the VEKi and multicast it to VEKi- 
members, notifying them not to obtain a derived VEKi. 



